§1.1 Field of the Invention
The invention concerns providing a transport network that supports virtual private networks. More specifically, the invention concerns providing a virtual private network with simplified, yet scalable, signaling.
§1.2 Related Art
The description of art in this section is not, and should not be interpreted to be, an admission that such art is prior art to the present invention.
§1.2.1 Known Private Networking Technologies
For many entities (such as businesses, universities, etc.), local area networks (LANs) suffice for intra-entity communications. Indeed, LANs are quite popular since they are relatively inexpensive to deploy, operate, and manage, and are based on mature, well-developed technology (such as Ethernet). Unfortunately, however, many entities need to communicate with their own facilities, or others, beyond their immediate location. Thus, wide area networks (WANs) are needed. Very often, entities want at least some privacy or security attached to their communications.
Dedicated WANs are typically implemented using leased lines or dedicated circuits to connect multiple sites. Customer premises equipment (CPE), such as routers or switches, connect these leased lines or dedicated circuits together to facilitate connectivity between each site of the network. Unfortunately, dedicated WANs are relatively expensive and typically require the customer to have some networking expertise. Public transport networks, which are typically deployed by regional bell operating companies (RBOCs), or some other service provider, are often used to allow remote users to connect an enterprise network using the public-switched telephone network (PSTN), an integrated services digital network (or ISDN), or some other type of transport network technology. Unfortunately, however, various incompatible public transport networks have been introduced over the years in response to the perceived needs to support various applications. Administering and maintaining these separate networks is expensive for those entities providing public transport network services. Virtual private networks (VPNs) have been introduced to permit wide-area communication without the drawbacks of WANs and public transport networks. Two of the more popular ways to implement VPNs, as well as their perceived shortcomings, are introduced in §§1.2.1.1 and 1.2.1.2.
§1.2.1.1 Layer 3 VPNs and Their Perceived Limitations
Layer 3 VPNs have been proposed. See, e.g., the paper E. Rosen et. al., “BGP/MPLS VPNs,” RFC 2547, The Internet Engineering Task Force, The Internet Society (March 1999) (This paper is incorporated herein by reference and hereafter referred to as “RFC 2547”). Unfortunately, layer 3 VPNs have a number of limitations. For example, RFC 2547 contemplated that PE routers would be administered solely by the service provider, and that the customers would have no access to PE administration. (See RFC 2547, §1.2.) Since the transport network is locked into BGP, if the customer uses an interior gateway protocol (IGP) such as open shortest path first (OSPF) or intermediate system-intermediate system (IS-IS), such protocols need to be mapped or otherwise converted to BGP if routing is to take place across the customer-service provider boundary. Similarly, hacks to BGP are necessary if the customer is running multicast.
§1.2.1.2 Virtual Router-Based VPNs and Their Perceived Limitations
The concept of using virtual routers (VRs) to support VPNs is addressed in the paper, Knight (Ed.), “Network based IP VPN Architecture using Virtual Routers,” Internet Draft draft-ietf-ppvpn-vr-03.txt, The Internet Engineering Task Force, The Internet Society (July 2002) (This paper is incorporated herein by reference and hereafter referred to as “the VR draft”). Departing from so-called “piggyback” models such as RFC 2547, which terminate a VPN network layer at the edge of a transport network (or “backbone”), the VR draft builds a VPN service using VRs. A VR can be thought of as a subset emulation of a real router, which has exactly the same mechanisms as a physical router, and therefore inherit all existing mechanisms and tools for configuration, operation, accounting and maintenance. That is, a VR is an emulation of a physical router at software and/or hardware levels. VRs have independent IP routing and forwarding tables and are isolated from each other. Within a VPN domain, a routing instance is used to distribute VPN reachability information among VR routers.
VPN members (i.e., nodes having VRs belonging to a VPN) can be “discovered” using various techniques, such as BGP for example. However, routes (or “reachability” information) are exchanged by running existing routing protocols on a per-VPN basis across the tunnels. (See, e.g., §6 of the VR draft.) Unfortunately, this later feature can lead to scalability problems. More specifically, most popular IGP routing protocols, such as OSPF and IS-IS, are so-called “link state routing” protocols. In link state routing protocols, neighbor devices are discovered, a delay or cost metric to each of the neighbor devices is determined, and this “link state” information is send to all other routers. Each router then uses this “network topology” information to determine paths, such as shortest paths or lowest cost paths, to the other routers in the network. Typically, link state information is distributed by flooding it out to all the participating neighbors. In a transport network where a PE may support multiple VPNS, each VPN may be formed by connecting all the VRs in the VPN on all participating PEs via tunnels in a full mesh. That is, each VR instance on each PE can flood link state information across all tunnels interfaced by the PE. This causes a lot of traffic over the network and therefore does not scale well to a large number of VPNs.
§1.3 Unmet Needs
Thus, an improved VPN is needed. Such a VPN should avoid the need for converting popular IGP protocols, running on customer devices, to a single protocol, such as BGP. Instead, such a VPN should allow customers to use popular IGP protocols, while avoiding scaling problems which might otherwise occur when an IGP floods link state information.